home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000168_misckit-reques…aska.et.byu.edu_Wed Apr 6 16:33:23 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  5KB
  1. Return-Path: <misckit-request@alaska.et.byu.edu>
  2. Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
  3.     id AA11819; Wed, 6 Apr 94 16:33:12 -0600
  4. Received: from YVAX2.BYU.EDU by alaska.et.byu.edu; Wed, 6 Apr 1994 16:24:55 -0600
  5. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-7 #4169)
  6.  id <01HAV0H0KTDSR5NACH@yvax.byu.edu>; Wed, 6 Apr 1994 16:24:45 MDT
  7. Received: from sonata.cc.purdue.edu by yvax.byu.edu (PMDF V4.3-7 #4169)
  8.  id <01HAV0GOSHLCQPGB2R@yvax.byu.edu>; Wed, 6 Apr 1994 16:24:29 MDT
  9. Received: from waltz.cc.purdue.edu by sonata.cc.purdue.edu (NX5.67e/Purdue_CC)
  10.  id AA20600; Wed, 6 Apr 94 17:24:16 -0500
  11. Received: by waltz.cc.purdue.edu (NX5.67e/NX3.0X) id AA08998; Wed,
  12.  6 Apr 94 17:24:14 -0500
  13. Received: by NeXT.Mailer (1.95)
  14. Received: by NeXT Mailer (1.95)
  15. Date: Wed, 06 Apr 1994 17:24:14 -0500
  16. From: kane@sonata.cc.purdue.edu (Christopher Kane)
  17. Subject: More Re: Comments on MiscAgent
  18. To: misckit@byu.edu
  19. Reply-To: kane@cs.purdue.edu
  20. Message-Id: <9404062224.AA20600@sonata.cc.purdue.edu>
  21. Content-Transfer-Encoding: 7BIT
  22.  
  23. Ernest Prabhakar <ernest@pundit.cithep.caltech.edu> writes:
  24. > The primary purpose of MiscAgent is to simplify the lazy loading
  25. > and initialization of resources by using the responder chain to
  26. > intercept messages. [Does "resources" basically mean either a nib
  27. > or a bundle, plus its constituents?]
  28.  
  29. "purpose of MiscAgent *might be* to simplify"; otherwise this is
  30. the general thought.
  31.  
  32. I used the phrase "birth of a notion" before; "conception" might
  33. have been a better term.
  34.  
  35. > 1) how does the object know which classes implement which methods
  36. > before loading.
  37.  
  38. As I've noted previously, this is one of the problems that needs
  39. resolving.  Some preprocessing at compile time into a class
  40. specification file is one possibility.
  41.  
  42. > 2) how to manage lots of overlapping, dynamically added classes
  43. > ("implicit programming" - I like the term!)
  44.  
  45. It depends on what you mean by "overlapping"; but this is something
  46. else that needs to be solved.
  47.  
  48. > 3) How to make this have no more overhead than direct connections?
  49.  
  50. To be blunt: you don't.  This is a classic power/speed tradeoff, like
  51. you learn about in high school physics (and that come up in computer
  52. science, too).  It would be the same overhead, plus a bit, that
  53. exists with NXBundles now; the first access can be quite slow.
  54.  
  55. > However, I think it needs to be as easy to setup a MiscAgent
  56. > connection as it is to perform a direct connection.  If one needs
  57. > to parse the nib, create a subclass, and resolve conflicts
  58. > manually, much of the advantage will be lost.
  59.  
  60. Well, you know about as much as I do about what might be eventually
  61. required.  Few things, though, are strictly drop-in and go.
  62.  
  63. > I suspect that if we are to find a truly usable suggestion, it would be
  64. > best to start with an existing situation and work to abstract it. Two
  65. > classes that come to mind are MiscNibController and MiscInfoController.
  66.  
  67. Exactly my plans.  I've got a directory into which I've copied these
  68. classes and some of my own (I've written a few of these Controller
  69. type classes for apps I've written).  But as well, I don't want to
  70. be limited to what these do, or to suggest to other people that these
  71. are examples of what I have in mind.
  72.  
  73.  
  74. yackd@alaska.et.byu.edu (Don Yacktman) writes:
  75. > I think the idea has merit, though, since it seems it could be more
  76. > extensible than the current solution.  The trick, as Ernie suggests,
  77. > is to make sure that we are reducing the complexity of the solution
  78. > and not increasing it.  That's never easy to do.  :-)
  79.  
  80. It depends on *where* you want to reduce complexity; again, this can
  81. be a tradeoff.  The easiest tools to use may have very sophisticated
  82. implementations.  (As a side note, though, I note that this isn't
  83. always true of tools.  A hammer is easier to operate than an automobile
  84. is easier to operate than a nuclear power plant.)
  85.  
  86. > I think the hardest part will be making it transparent to set up
  87. > knowing what methods a class responds to before it is loaded.  You
  88. > kind of need a flat file--"object.info" or somesuch--inside the
  89. > bundle that the MiscAgent can look at before loading the bundle.
  90.  
  91. This (problem) also forces generality onto the MiscAgent.
  92.  
  93.  
  94. For the past few days, thinking about this, I've had the feeling that
  95. if only the Objective-C runtime where written in Objective-C (ie,
  96. an NXObjCRuntime class, or Class objects that were fully objects, or
  97. somesuch) that the reasons for having MiscAgent would go away, since
  98. there would be a more appropriate place (and simpler implementation)
  99. at which to modify the runtimes behavior (well, the AppKit's behavior,
  100. too).  And a few compiler/linker changes as well...  Ah, well...
  101.  
  102. You know, when NS 3.0 (3.1?) came out, there was talk (rumor?) that
  103. bundles were the way of the future; nearly everything would be
  104. "bundled", loaded on demand (though with disk access being a significant
  105. limiting factor, one wonders if this would ever be popular).  If
  106. this is the case (for NS 4.0, possibly), then the compiler and runtime
  107. changes must already be under way (if not done) at NeXT.
  108.  
  109. Well, one can dream...
  110.  
  111. Christopher Kane